Streaming live or prerecorded media content to client devices such as set-top boxes, computers, smartphones, mobile devices, tablet computers, gaming consoles, and other devices over networks such as the internet has become increasingly popular. Delivery of such media content commonly relies on adaptive bitrate streaming technologies such as MPEG-DASH, HTTP Live Streaming (HLS), and HTTP Smooth Streaming.
A stream of media content encoded with adaptive bitrate streaming techniques is generally divided into multiple segments, each of which can be independently accessible. A client device can play a media stream by requesting and decoding a first segment, requesting and decoding a second segment, and continuing to request and decode subsequent segments for as long as the user of the client device desires to play the media content, or until playback reaches the end of the media content.
Additionally, segmentation of a stream can allow a client device to transition between different bitrate versions of the stream that have each been encoded at different quality levels. For instance, when network conditions are congested, a client device can begin playback of a media stream by requesting segments encoded with a low bitrate, but when network conditions improve the client device can transition to a higher quality version of the stream by requesting subsequent segments encoded at a higher bitrate.
While segmenting a media stream can be useful, conventional segmentation processes introduce delays, especially with transmission of live content. In most adaptive bitrate streaming implementations, a server can only provide complete segments to requesting client devices. However, segments generally have a length of at least a few seconds, such as 2 to 10 seconds. As such, initial delivery of the stream to end users cannot begin until the first segment is complete. This introduces a delay of at least the length of the segment before otherwise live content can be viewed. Additionally, because the first segment is delayed in this manner, all subsequent segments will be similarly delayed and the video will never catch up to real time.
These types of delays can be frustrating for users. For instance, live sports broadcasts are popular, and viewers generally would like to see events on screen as soon as possible after they occur in the stadium. However, even if the length of each segment is relatively short, such as two seconds, each two seconds of content must be completely encoded and encapsulated into a segment before it can be sent to client devices. As such, events shown on screen will always be at least two seconds behind real-time due to the segmentation process. Such delays can be disappointing for fans, because when an exciting event happens during a game, they may learn about it first through an online scoreboard or over the radio before they actually see it happen on screen.
While some viewers may not care if live video is received on a delayed basis, those viewers can still be irritated by the time it takes to begin viewing a video stream. Because the first video segment needs to be completely encoded and encapsulated before it can be sent to the viewer's device, there can be a delay at least equal to the segment size, such as 2-10 seconds, after the viewer requests the video stream before it begins playing for the viewer. For viewers accustomed to the immediate tuning times offered by conventional television, a multi-second tuning delay can be frustrating.
One approach to decreasing this type of tuning delay can be to shorten the segment size. For example, instead of the 10 second segments commonly used in some current streaming technologies, the segment size could be shortened to 2 seconds so that the decoding device can begin playback after receiving the first 2 seconds of content. However, all segments are generally encoded with a leading anchor frame that uses more data than other frames. As such, decreasing the segment size requires more anchor frames and utilizes more data, which can decrease coding efficiency and impact bandwidth usage and performance. Additionally, decreasing the segment size would result in more segments overall, and would accordingly increase the number of HTTP requests and replies needed to deliver them to client devices.